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Bitwise Monitoring of Network Performance 

CROSS REFERENCE TO RELATED APPLICATIONS 

1. This application is a continuation-in-part of application no. 09/550,955, filed April 
17, 2000, which claims priority under 35 U.S.C. § 1 19(e) from provisional application no. 
60/190,691, filed March 20, 2000. The 09/550,955 application and the 60/190,691 
application are both incorporated by reference herein, in their entireties, for all purposes. 

2. This application claims priority under 35 U.S.C. § 1 19(e) from provisional 
application no. 60/216,662, filed July 6, 2000. The 60/216,662 application is incorporated 
by reference herein, in its entirety, for all purposes. 

INTRODUCTION 

3. The present invention relates generally to a method and system for measuring 
quality of service in a wireless network. More particularly, the present invention relates to 
a method and system for measuring quality of service in a wireless network using multiple 
remote units and a back end processor. 

BACKGROUND OF THE INVENTION 

4. There are two major technical fields that have shown explosive growth over the 
past few years: the first is wireless communications and the second is use of data services, 
particularly the Internet. These two technical fields both require a set of specialized tools 
in order to measure their quality of service. Interestingly, wireless communications and 
data services are beginning to converge. Unfortunately, this convergence has not been 
accompanied by the development of appropriate specialized tools to measure data quality 
of service in the wireless network. 

5. The growth of wireless communications has been astounding. Twenty years ago, 
there was virtually no use of wireless communications devices such as cellular phones. In 
contrast, the market penetration for wireless devices in the U.S. in 1999 was 32 percent. 
The current forecast is that 80 percent of the U.S. population will be wireless subscribers 
by 2008. 

6. There are a variety of specialized tools that are used to measure quality of service 
over wireless networks. These include the following (just to name a few examples): 
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Ascom QVoice (including QVoice unattended); 

Ericsson TEMS, RSAT-2000, Benchmarker, CellAD, and CeNA; 

Nokia TOM; 

Safco VoicePrint, DataPrint, and WalkAbout; 

Comarco BaseLINE and Gen II; 

Grayson Surveyor; 

ZK CellTest DX136 and DXC; 

Ameritec Swarm; 

Neopoint Datalogger; and 

Qualcomm QCTest Retriever and QCTest CAIT. 

7. The general deficiency with these tools is that they were primarily developed to 
measure voice quality and/or RF parameters over the wireless system and not to measure 
data quality. Some of them have been modified to include some rudimentary data 
measurements; however, they are not optimized for performing wireless data 
measurements. In particular, they do not allow unattended measurement of wireless data 
from multiple remote units in a statistically significant manner with remote control from a 
back end processor. 

8. The classical way of measuring voice quality of service and/or RF parameters in a 
wireless network involves sending out technicians to drive test the network. The drive test 
includes placing the test instrument in a vehicle and running a test script that either 
generates or receives a voice test signal. The receiving end of the communication link 
uses a DSP containing a model of human hearing to analyze the received voice sample and 
produce an associated quality score. In addition, some of the systems measure other 
system parameters such as SINAD, noise, distortion, received signal level, and call 
progress statistics. 

9. Unfortunately, the classical method of measuring voice quality of service and/or 
RF parameters does not function very well for measuring data quality of service. In order 
to make statistically significant measurements of data quality of service over a wireless 
network, it is necessary to make multiple measurements from multiple remote devices. 
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Furthermore, a measurement of data quality is inherently different from the other types of 
measurements due to the effects of latency and other effects that are specific to data. 

10. Most of the existing measurement devices do not have this capability for a variety 
of reasons. The price of the test instruments range anywhere from $5K to $100K. This 
makes it price prohibitive to field a statistically significant fleet of remote devices. Thus, 
what is needed are remote devices designed for unattended operation that is remotely 
controlled by a back end processor in order to reduce manpower costs. Additionally, what 
is needed are remote devices that are optimized for performing measurements that are 
useful over wireless data networks, such as latency for Web page access or delay in SMS 
message delivery. 

1 1 . The growth of data services has been just as astounding as the growth rate for the 
wireless industry. The largest driving force behind the growth of data services has been 
the enormous growth of the Internet. For example, there were 130 Web sites in June 1993, 
230,000 Web sites in June of 1996, and 10 million Web sites at the end of 1999. 

12. There have been a variety of specialized tools developed to measure the data 
quality of service over the Internet. 

13. U.S. Patent No. 6,006,260 to Barrick, Jr. et al. (assigned to Keynote Systems, Inc) 
discloses a method for gathering latency experienced by a user over a network. The steps 
of the method include a user browser sending a GET command to retrieve an HTML page 
with an embedded Java script. The Java script starts a timer and generates a GET 
command to retrieve an HTML page. When the page is received, the timer is stopped and 
the timer information along with cookie data stored on the browser machine is sent to a 
relay server that logs the information. 

14. U.S. patent No. 5, 657,450 to Rao et al. teaches the provision of time estimates for 
long-running distal source access operations using an intermediate server close to the 
client workspace. 

15. U.S. patent No. 5, 796, 952 to Owen et al. discloses a method for monitoring a 
user's time of page browsing. 
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16. U.S. patent No. 6, 012,096 to Link et al. teaches a method for monitoring client-to- 
client network latency for gaming applications. The method involves a ping, response, 
and response-response protocol. 

17. Unfortunately, none of these patents teach a method which is appropriate for 
performing data quality of service measurements over a wireless network. 

18. As previously mentioned, there is a tremendous convergence taking place that 
combines the wireless network with data services. Dataquest estimates that the U. S. 
wireless data market (including phones, PDAs, laptops, and the like.) will grow from 3 
million subscribers in 1999 to 36 million subscribers in 2003. Ericsson is estimating that 1 
billion wireless units will be in use worldwide by 2003 and that 40 percent (400 million) 
of these units will be employed by data users. Furthermore, Ericsson is predicting that 
2003 will be the crossover year in which wireless Web access will exceed wired Web 
access. 

19. As a further measure of the explosive growth of the convergence of the wireless 
systems and the Internet, one can look at projections for the number of wireless portal 
subscribers. According to the Strategis Group, the number of wireless portals will 
increase from 300,000 in 2000, to 9.8 million in 2003, and finally to 24.8 million in 2006. 

20. A variety of technical advancements have accelerated the convergence of Internet 
access over wireless devices. In 1997, three competing handset vendors (Nokia, Ericsson, 
and Motorola) and a small software company (Phone.com, formerly Unwired Planet) 
joined forces to create a standard way to transmit Internet data to wireless phones without 
occupying too much bandwidth. The result of this collaboration was development of the 
wireless application protocol (WAP). One basic component of WAP was development of 
the WML (Wireless Markup Language, replacing the previous Phone.com Handheld 
Device Markup Language, HDML) that compresses Web content in comparison to 
HTML. Additionally, the WAP forum developed standards for the use of microbrowsers 
in mobile devices. 

21 . Unfortunately, the development of wireless Web access technology has 
significantly outpaced the development of wireless data measurements tools. 
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Accordingly, there is a tremendous need for specific test tools to address the converging 
technologies of wireless systems and data communications. 

SUMMARY OF THE INVENTION 

22. In order to meet this need, a measuring tool is provided for measuring data quality 
of service over the wireless network. This tool was designed from the ground up with a 
variety of specific attributes. 

23. The present invention provides for a method and system for measuring data quality 
of service in a wireless network using multiple peripatetic (i.e. mobile) and/or stationary, 
unattended, position and performance instruments (PUPPIs) that are remotely controlled 
by a back end processor. According to some embodiments of the invention, the data 
service whose quality is measured relates to wireless Internet access, e-commerce 
transactions, wireless messaging, or push technologies. According to other embodiments 
of the invention, the system includes an element that is located within the wireless network 
infrastructure, for example, at the WAP gateway to monitor the wireless data protocol and 
to perform benchmarking measurements. 

24. The remote unit is able to provide an appropriate statistical distribution for data 
measurements. The remote units can be peripatetic (i.e. mobile) so that they are able to 
roam over a statistically significant geographical area, or stationary with pre-planned 
location at statistically significant points, or some combination of mobile and stationary. 

25. Furthermore, the system includes multiple remote units that are unattended and are 
remotely controlled by a back end processor. This allows for a large quantity of 
measurements to be taken in a fully automated manner. 

26. Additionally, each of the remote units provides position information for each 
measurement as well as performance information that is related to wireless data. More 
specifically, the performance information may be related to wireless Internet access, e- 
commerce transactions, or wireless messaging using either push or pull technologies. 

27. For example, one of the most critical measurements for the wireless Internet user is 
a measurement of the latency, i.e. the amount of time it takes to receive a response after a 
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GET command is sent. In the case of wireless messaging, the latency measurement 
includes the amount of time required to receive information after it is sent from the source. 

28. In addition, it is useful to perform measurements which divide the network into a 
wireless and wired portion and that provide separate measurements for each portion. 
Accordingly, the system may include an element that is located within the wireless 
network infrastructure, for example at the WAP gateway, to monitor the wireless data 
protocol and to perform benchmarking measurements. 

29. Accordingly, an object of the present invention is to provide a method and system 
for measuring data quality of service in a wireless network using multiple remote units and 
a back end processor. 

30. A further object of the invention is to perform these measurements on a variety of 
different types of traffic wireless networks, such as iDEN, CDMA, TDMA, and GSM, for 
example. 

3 1 . Another objective of the invention is to perform these measurements during a 
variety of different types of communications such as circuit switched calls, packet data 
calls, SMS messages, wireless internet access, wireless internet transactions (including e- 
commerce), and during the reception of push data (i.e. data which is delivered using push 
technology). 

32. A further objective of the invention is to collect a variety of different types of 
measurements such as latency measurements, reliability (e.g. BER/FER), layer 3 network 
information, RF information, call connection information, and the like. 

33. Another objective of the invention is to use control links that are either wired or 
wireless. 

34. A further objective of the invention is to use remote units that are either mobile, 
stationary, or some combination of mobile and stationary so that they provide statistically 
significant measurements. 

35. Another object of the invention is to provide a back end which allows user access 
through the Internet, allows for post-processing of the received data, allows for scheduling 
collection missions based on available resources, and allows for generation of test traffic. 
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36. An additional object of the invention is to provide a remote unit that allows for 
storage and pre-processing of the measured data, battery backup, and an RF scanner. 

37. Advantages of the current invention include the ability to collect statistically 
significant data in an extremely cost effective and easy to use manner. 

38. Additional objects and advantages of the present invention will be apparent in the 
following detailed description read in conjunction with the accompanying drawing figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

39. FIGS, la-g show a generic communication network with a variety of wireless 
communication paths connected to the Internet. 

40. FIG. la shows the communication path for the traffic data in a standard wired 
Internet measurement system. 

4 1 . FIG. 1 b shows the communication path for the traffic data during a circuit 
switched data connection in accordance with an embodiment of the invention. 

42. FIG. lc shows the communication path for the traffic data during a packet 
switched data connection in accordance with an embodiment of the invention. 

43. FIG. Id shows the communication path for the traffic data during an SMS message 
transmission in accordance with an embodiment of the invention. 

44. FIG. 1 e shows the communication path for the traffic data during a WAP data 
connection in accordance with an embodiment of the invention. 

45. FIG. If shows the communication path for the traffic data during a WAP data 
connection in accordance with a further embodiment of the invention. 

46. FIG. lg shows the communication path for the traffic data during a WAP data 
connection, including a WAP monitoring processor, in accordance with a further 
embodiment of the invention. 

47. FIG. lh shows the communication path for the control link in accordance with an 
embodiment of the invention. 

48. FIG. 2a shows the system architecture in accordance with one embodiment of the 
invention. 
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49. FIG. 2b shows the system architecture in accordance with a further embodiment of 
the invention. 

50. FIG. 2c shows the system architecture in accordance with another embodiment of 
the invention. 

51. FIG. 2d shows the system architecture in accordance with a further embodiment of 
the invention. 

52. FIG. 2e shows the system architecture in accordance with another embodiment of 
the invention. 

53. FIGS. 3a through 3d show a variety of basic architectures for remote units 
according to various embodiments of the invention. 

54. FIG. 3a shows the basic architecture for the remote unit in accordance with one 
embodiment of the invention. 

55. FIG. 3b shows another architecture for the remote unit with separate control link 
modem and traffic modem according to an alternate embodiment of the invention. 

56. FIG. 3c shows another architecture for the remote unit with separate control link 
modem and multiple traffic modems according to another alternate embodiment of the 
invention. 

57. FIG. 3d shows a further architecture for the remote units that include multiple 
peripherals in accordance with one embodiment of the invention. 

58. FIGS. 4a through 4d show a variety of alternate implementations for the remote 
unit in accordance with one embodiment of the invention. 

59. FIG. 4a shows a hardware implementation of the remote unit using either a laptop 
or handheld unit in accordance with one embodiment of the invention. 

60. FIG. 4b shows a hardware implementation of the remote units using a single board 
computer (SBC) in accordance with one embodiment of the invention. 

61. FIG. 4c shows the organization of the software-defined radio in accordance with an 
embodiment of the invention. 
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62. FIG. 4d shows the organization of the software in the remote unit in accordance 
with an embodiment of the invention. 

63. FIG. 5a shows the architecture of the back end processor in accordance with one 
embodiment of the invention. 

64. FIG. 5b shows the architecture of the back end processor in accordance with an 
alternate embodiment of the invention. 

65. FIG. 5c shows the architecture for the portal in accordance with one embodiment 
of the invention. 

66. FIG. 6a shows examples of some of the fields in the remote unit originated packets 
(both data and signaling) in accordance with one embodiment of the invention. 

67. FIG. 6b shows examples of some of the fields in the back end processor originated 
packets (both data and signaling) in accordance with one embodiment of the invention. 

68. FIG. 7a shows a method for measuring data quality of service in a wireless 
network in accordance with one embodiment of the invention. 

69. FIG. 7b shows a method for measuring data quality of service in a wireless 
network, including at least one step related to the wireless network infrastructure, in 
accordance with an alternate embodiment of the invention. 

70. FIG. 7c shows a method for measuring data quality of service in a wireless 
network, including at least one additional order independent step, in accordance with 
another embodiment of the invention. 

71 . FIG. 8a shows a bar graph output of download times from different portals in 
accordance with an embodiment of the invention. 

72. FIG. 8b shows a bar graph output of download times across different wireless 
networks in accordance with an embodiment of the invention. 

73. FIG. 8c shows a bar graph output of call completion percentage across different 
wireless networks in accordance with an embodiment of the invention. 

74. FIG. 8d shows a trending graph output of call completion percentage across 
different wireless networks in accordance with an embodiment of the invention. 
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75. FIG. 8e shows a bar graph output of average download times with a breakdown of 
the network latency at the WAP gateway in accordance with an embodiment of the 
invention. 

76. FIG. 8f shows a pie chart of error statistics for wireless access of Yahoo in 
accordance with an embodiment of the invention. 

77. FIG. 9 illustrates a system according to an exemplary embodiment of the present 
invention. 

78. FIG. 10 illustrates remote units (PUPPIs) in the exemplary system. 

79. FIG. 1 1 illustrates processes that each contain software modules that are 
responsible for specific tasks. 

80. FIG. 12 illustrates a router is used as the interface between an external 
communication line and a LAN that is connected to the PUPPIs. 

81. FIG. 13 illustrates the basic architecture for the Back End according to the 
exemplary embodiment. 

82. FIG. 14 illustrates two basic software modules included in the Back End. 

83. FIG. 15 illustrates hardware architecture for the Back End according to the 
exemplary embodiment. 

DETAILED DESCRIPTION 
I. Overview 

84. In order to understand the present invention, it is helpful to compare the 
communication path of current data measurements tools with the communication path in 
accordance with several embodiments of the invention. FIGS, la-g show a generic 
communication network with a variety of wireless communication paths connected to the 
Internet. It is well known to those of ordinary skill in the art that these figures illustrate a 
generic network that is used for illustrative purposes. For example, in some cellular 
networks there is a base station controller connected to multiple base stations between 
their connections to the MSC. As another example, the WAP gateway, packet data 
gateway, and PSTN connection may be replaced in some wireless networks by a single 
device that is directly connected to the MSC. 
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85. FIG. la shows the communication path (heavy broken line) for the traffic data in a 
standard wired Internet measurement system. The traffic data flows between the user 
machine 124 over the Internet 122 to a standard application server 126 that will generally 
be serving an HTML page. 

86. FIG. lb shows the communication path (heavy broken line) for the traffic data 
during a circuit switched data connection in accordance with an embodiment of the 
invention. The traffic data passes from the remote unit 102-lto the base station 106, MSC 
108, PSTN 110, ISP 112, Internet 122, and to a standard application server 126. The 
standard application server 126 may be serving an HTML page, for example. 

87. FIG. lc shows the communication path (heavy broken line) for the traffic data 
during a packet switched data connection in accordance with an embodiment of the 
invention. The traffic data passes from the remote unit 102-1 to the base station 106, MSC 
108, operator backbone 114, packet data gateway 118, Internet 122, and standard 
application server 126. For example, the standard application server 126 may be serving 
an HTML page. 

88. FIG. Id shows the communication path (heavy broken line) for the traffic data 
during an SMS message transmission in accordance with an embodiment of the invention. 
If the SMS message is being delivered to the remote unit 102-1, the traffic data passes 
from a standard application server 126 to the Internet 122, SMSC 116, operator backbone 
114, MSC 108, base station 106, and remote unit 102-1. 

89. FIG. le shows the communication path (heavy broken line) for the traffic data 
during a WAP data connection in accordance with an embodiment of the invention. If the 
remote unit 102-1 is accessing a WAP server 128, the traffic data passes from the remote 
unit 102-1 to a base station 106, MSC 108, operator backbone 114, WAP gateway 120, 
Internet 122, and WAP server 128. For example, the traffic data path shown in FIG. le 
allows for latency measurements for wireless Web page access or e-commerce 
transactions. 

90. It is important to note that although the term WAP is being applied to the wireless 
Internet protocol, the principles of the present invention are not limited to a WAP 
implementation. The present invention may be implemented using any wireless Internet 
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protocol, including HDML and any future wireless Internet protocols that may be 
developed. The following examples are provided of some competing technologies that for 
the purposes of this disclosure will be considered to be functionally equivalent to WAP. 
For example, the Web content can be delivered as text messaging or as an SMS message 
(as proposed by Xypoint or GoSMS) so that it is compatible with existing cellular phones. 
Alternatively, the Web content can be delivered as existing HTML Internet content for 
wireless devices as proposed by Spyglass' Prism technology or Japan's iMode. As a 
further example, the content can be processed through a template model that reads existing 
HTML content and fits the data to a template optimized for various types of wireless 
phones such as the system proposed by Everypath.com. As another example, the data 
content can be delivered to a Palm Pilot or other PDA or handheld device that uses a 
proprietary protocol. 

91 . Additionally, it is noted that the present invention is not limited to use of the 
Internet, as it may be effectively practiced using any broad-reach network regardless of 
hardware implementation specifics. Accordingly, the term Wireless Data Protocol (WDP) 
will be used interchangeably with the generically used term WAP to describe the protocol 
used for wireless data access. 

92. FIG. If shows the communication path (heavy broken line) for the traffic data 
during a WAP data connection in accordance with a further embodiment of the invention. 
If the remote unit 102-1 is accessing the benchmark WAP server 130, the traffic data 
passes from the remote units 102-1 to a base station 106, MSC 108, operator backbone 
114, WAP gateway 120, and to the benchmark WAP server 130. This configuration 
allows latency measurements without including the uncertainties of the latency through the 
Internet 122 itself. In other words, the configuration in FIG. If allows measurements of 
the latency due to the wireless network itself with no contribution from the Internet 122. 

93. FIG. lg shows the communication path (heavy broken line) for the traffic data 
during a WAP data connection, including a WAP monitoring processor 132, in accordance 
with a further embodiment of the invention. The WAP monitoring processor 132 may be 
implemented as monitoring software installed and running on the WAP Gateway 120 or as 
software installed on a separate machine attached to the WAP Gateway 120. The software 
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would monitor traffic through the WAP Gateway 120 and provide metrics such as 
throughput, latency and lost packet information. This configuration would allow the 
wireless network and the Internet 122 itself to be analyzed and monitored separately, thus 
providing performance information for each. Furthermore, the WAP Monitoring 
Processor 132 would be able to collect protocol information directly from the WAP 
Gateway 120 that may not be available to the multiple remote units (102-1 through 102- 
N). 

94. The monitoring software may run as a separate application on the WAP Gateway 
120, or may be embedded into the WAP Gateway software itself and run as part of the 
entire gateway application. The monitoring software would have a mechanism for 
collecting metrics and passing that information to the back end processor through the 
internet, wireless network, or through some other means. The monitoring software may 
temporarily store results locally, and perform some pre-processing on the data prior to 
forwarding it to the back end processor. 

95. FIG. lh shows the communication path for the control link in accordance with an 
embodiment of the invention. The control link is used to remotely control the remote units 
140, 142, 144, 146 from the back end processor 148. Specifically, the process in the back 
end processor 148 that communicates with the remote units 140, 142, 144, 146 is the fleet 
management process, which will be discussed in detail later. 

96. The remote units can be either mobile 140, 142, 144 or stationary 146. The mobile 
units 140, 142, 144 can be mounted in a variety of vehicles such as taxis, police cars, 
buses, postal vehicles, delivery vehicles, fleet vehicles, just to give a few examples. The 
stationary remote units 146 can be mounted in any area in which the public congregates 
and uses wireless devices. This includes airports, bus stations, and train stations just to 
provide a few examples. 

97. A variety of communication technologies are available to implement the control 
link. The control link can be implemented as data running over any of the current wireless 
networks such as CDMA, iDEN, TDMA, or GSM just to name a few examples. 
Additionally, the control link can be implemented over the AMPS network using CDPD 
for example. Alternatively, the control link can be implemented using a two-way data 
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system such as ARDIS, MOBITEX, SKYTEL, and the like. 

II. System Architecture 

98. FIG. 2a shows the system architecture in accordance with one embodiment of the 
invention. As previously described, the invention comprises multiple remote units (202-1 
- 202-N) that may be either mobile or stationary. Each remote unit may include a location 
unit (202a-l - 202a-N) that allows the remote unit to accurately determine its location. 
Furthermore, each remote unit includes a communications link (202b-l - 202b-N) that 
provides for both the control link and the traffic data. The communications link 202b-l 
communicates over a communication network 210 that passes the information to a 
communication server 212 that connects to a data network 220. The data network 220 can 
be a public data network, such as the Internet, or a private data network. A back end 
processor 224 is connected to the data network 220 for handling control link information, 
both commands and responses, and traffic data. In addition, the customers 222 are also 
connected to the data network so that they can access the back end processor 224. 

99. FIG. 2b shows the system architecture in accordance with a further embodiment of 
the invention. The system in FIG. 2b differs from the system shown in FIG. 2a in that the 
control link network and the traffic data network are two separate communication 
networks. Each remote unit (e.g., 202-1) may include a location unit 202a-l that allows 
the remote unit 202-1 to accurately determine its location. Furthermore, each remote unit 
202-1 includes a control link communication module 202c-l and a traffic data 
communication module 202d-l. The control link 202c-l passes commands and response 
information through communication network A 210A and communication server A 212A 
to the data network 220. The traffic data communication module 202d-l passes traffic 
data through communication network B (210B) and communications server B (212B) to 
the data network 220. A back end processor 224 is connected to the data network 220 for 
handling control link information, both commands and responses, and traffic data. In 
addition, the customers 222 are also connected to the data network 220 so that they can 
access the back end processor 224. 

100. FIG. 2c shows the system architecture in accordance with another embodiment of 
the invention. The system shown in FIG. 2c differs from the system shown in FIG. 2b in 
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that each remote unit (e.g., 202-1) may have multiple traffic modules (202dl-l - 202dN- 
1). Each remote unit 202-1 may include a location unit 202a-l that allows the remote unit 
to accurately determine its location. Additionally, each remote unit 202-1 includes a 
control link communication module 202c-l and includes multiple traffic data 
communication modules (202dl-l - 202dN-l). The control link passes command and 
response information through communication network A 2 10 A and communication server 
A 212A to the data network 220. Each traffic data communication module 1 through N 
(202dl-l - 202dN-l) passes traffic data through communication network B-l (210B-1) 
through B-N (210B-N), respectively, and through communication servers B-l (212B-1) 
through B-N (212B-N), respectively, to the data network 220. A back end processor 224 
is connected to be data network 220 for handling control link information, both commands 
and responses, and traffic data. In addition, the customers 222 are also connected to the 
data network 220 so that they can access the back end processor 224. 

101 . FIG. 2d shows the system architecture in accordance with a further embodiment of 
the invention. The system in FIG. 2d differs from the system shown in FIG. 2c in that 
multiple control link communication networks may be used. This is particularly important 
in systems in which the remote units are deployed in different cities. It may be preferable 
in this case to use a different control link communication network in different cities 
depending on the wireless system coverage and the data pricing structure. 

102. Each remote unit (202-1 - 202-N) may include a location unit (202a-l - 202a-N) 
that allows the remote unit to accurately determine its location. Furthermore, each remote 
unit (202-1 - 202-N) includes a control link communication module (202c-l - 202c-N) 
and includes multiple traffic data communication modules (202dl-l - 202dN-l - 202dl- 
N - 202dN-N). The control link passes commands and response information through one 
of communication network A-l (210A-1) through A-N (210A-N) depending on the 
appropriate communication network for the specific remote unit. Each control link 
communication network A-l (210A-1) through A-N (210A-N) is connected to a respective 
communication server A-l (212A-1) through A-N (212A-N) which allows command and 
response information to be passed to the data network. Each traffic data communication 
module 1 (202dl-l) through N (202dl-N) passes traffic data through communication 
network B-l (210B-1) through B-N (210B-N), respectively, and through communication 
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servers B-l (212B-1) through B-N (212B-N), respectively, to the data network. A back 
end processor 224 is connected to the data network 220 for handling control link 
information, both commands and responses, and traffic data. In addition, the customers 
222 are also connected to the data network 220 so that they can access the back end 
processor 224. 

103. FIG. 2e shows the system architecture in accordance with another embodiment of 
the invention. The system in FIG. 2e differs from the system shown in FIG. 2d in that 
both mobile and stationary remote units are shown. Because the traffic data 
communication channels in FIG. 2e are the same as those in FIG. 2d, they have been 
omitted in order to simplify the diagram. The control links for the mobile remote units 
(202-1 through 202-N) are the same as those described in FIG. 2d. 

104. Each stationary remote unit (202-X through 202-Y) may include a location unit 
(202a-X through 202a- Y) that allows the remote unit to accurately determine its location. 
The location unit (202a-X through 202a-Y) is generally optional in the stationary remote 
units since their location is presumably known. The stationary remote units each include a 
control link module (202c-X through 202c- Y) which is connected via a respective wired 
line to a respective communication network C-l (210C-1) through C-N (210C-N) and 
associated communication server C-l (212C-1) through C-N (212C-N) which allows 
command and response information to be passed to the data network 220. A back end 
processor 224 is connected to be data network 220 for handling control link information, 
both commands and responses, and traffic data. In addition, the customers 222 are also 
connected to the data network 220 so that they can access the back end processor 224. 

III. Remote Unit 

105. The remote unit has a variety of attributes in accordance with one embodiment of 
the invention. The remote unit should preferably be portable in terms of size and weight 
so it can be deployed in a vehicle or in a stationary public area. Possible vehicles include 
buses, police vehicles, taxis, postal vehicles, delivery vehicles, and fleet vehicles just to 
name a few. Examples of stationary public areas include airports, train stations, bus 
stations, and any public area where large numbers of people use wireless devices. 

106. Another attribute of the remote unit is that it is mountable either in a vehicle or in a 



- 16- 



Atty. Dkt. No.: 250 




public area. There are a variety of methods that can be used for mounting the remote unit. 
For example, the remote units can be mounted to a DIN bar that is commonly used for 
industrial equipment. Alternatively, the remote units can be mounted using a standard 
bracket, tie device, fabric strap, bolts, or adhesive device such as Velcro, for example. 

107. A further attribute of the remote unit is that it is able to withstand a wide 
temperature range such as the industrial temperature range of -40 degrees C to + 80 
degrees C, for example. This attribute allows deployment of the remote unit in a wide 
range of geographical environments. Furthermore, it allows deployment of the remote 
unit in places such as the trunk of a vehicle in which airflow is limited. 

108. Another attribute of the remote unit is the ability to withstand vibration. This 
attribute is important since many of the remote units may be deployed in vehicles and will 
be subjected to severe vibration. There are a variety of standard techniques that can be 
used to improve the vibration performance of the remote unit. These include using 
frequency absorbing mounting materials and potting the components on the printed circuit 
board for added stability. 

109. A further attribute of the remote unit is that it meets all local standards for 
emissions, both radiated and conductive. For example in United States, the emissions 
from most digital devices are covered by FCC part 15 and emissions from cellular devices 
are covered by FCC part 22. In Europe, there generally are directives which cover 
radiated emissions, conductive emissions, and radiated immunity and which must be met 
in order to receive the CE mark. 

1 1 0. Another attribute of the remote unit is the ability to handle the input power source. 
First, the remote unit should include some type of power regulation. This is particularly 
important in a vehicular environment in which the power provided by the vehicle battery 
is very noisy. Additionally, the remote unit should include the ability to power any 
external modules or peripherals that are going to be attached to the main control unit. 
Furthermore, the remote units may include some form of battery backup with an automatic 
charger so that the remote unit in a mobile environment does not drain the vehicle battery 
when the ignition is turned off. This requirement is not as important in a stationary 
deployment since the power can be provided from an AC outlet using a DC transformer. 
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However, one may choose to include the battery and charger in this configuration also in 
order to provide battery backup in the event of an AC power failure. Finally, the remote 
unit may include some form of sleep mode which is used to conserve power during 
periods of sporadic activity. 

111. The remote unit will now be described with regard to a variety of embodiments in 
accordance with the invention. FIGS. 3a through 3d show a variety of basic architectures 
for the remote unit. FIGS. 4a through 4d show a variety of possible implementations for 
the remote unit. 

1 12. FIG. 3a shows the basic architecture for the remote unit in accordance with one 
embodiment of the invention. The remote unit 300 comprises a control unit 302, a 
location unit 304, and a control link and traffic modem 306. The control unit 302 is the 
main control device for the remote unit 300 and is connected to the location unit 304 and 
the control link and traffic modem 306. The location unit 304 determines the location of 
the remote unit 300. 

113. The control link and traffic modem 306 shown in FIG. 3a is used to communicate 
with the back end processor 224. The control link and traffic modem 306 is connected to 
the control unit 302 in order to send and receive control information and traffic 
information. The control unit is generally running a main program that controls the 
location unit 304 and the control link and traffic modem 306. 

1 14. There are a variety of ways in which the location unit 304 can determine the 
location in accordance with the invention. The location unit 304 may comprise a GPS 
receiver such as those manufactured by Trimble, Ashtech, Garmin, or Magellan, for 
example. If the location unit 304 is a GPS receiver, the connection to the control unit 302 
may be a serial communication link. In another embodiment, the location unit 304 may 
comprise a GPS daughterboard such as those manufactured by Avocet, Trimble, Ashtech, 
or Rockwell, for example. If the location unit 304 is a GPS daughterboard, the connection 
to the control unit 302 is usually through a proprietary connector mounted on the control 
unit 302. The control of the GPS daughterboard is generally accomplished using a serial 
connection. In a further embodiment of the invention, the location unit 304 may comprise 
a GPS chipset or a single GPS chip which is mounted directly on the control unit 302 and 



- 18- 



Atty. Dkt.No.: 250' 



which has a bus interface. Furthermore, any of the GPS implementations of the location 
unit can include differential GPS using RTCM or RTCA corrections or alternatively can 
include WAAS capabilities. 

115. It is well known to those of ordinary skill in the art that there are a variety of 
alternative implementations for the location unit that don't involve standard GPS. For 
example, one can use a distributed GPS system, such as the one developed by SnapTrack, 
in which part of the GPS functionality is handled by a centralized server. Another 
alternative location option is the use of a triangulation technique using either angle of 
arrival or time difference of arrival information. Although the generic term triangulation 
is used, there is no requirement that three measurement points be used. A further location 
option is the use of RF fingerprinting, such as that developed by U.S. Wireless, which 
determines the unit location based on a multipath signature. 

1 16. Those of ordinary skill in the art will understand that FIGS. 2a-e, 3a-d, and 4a 
show logical antennas rather than physical antennas. These logical antennas can be 
combined in virtually any combination into a single physical antenna or groups of physical 
antennas depending on the specific requirements. 

1 17. FIG. 3b shows another architecture for the remote unit 300 with separate control 
link modem 308 and traffic modem 310 in accordance with a further embodiment of the 
invention. FIG. 3b differs from FIG. 3a in that the single control link and traffic modem 
306 has been divided into a separate control link modem 308 and traffic modem 310. The 
advantage of separating the control link modem 308 from the traffic modem 310 is that it 
allows the remote unit 300 to communicate control information and traffic information 
over different communication networks. 

118. It is well known to those of ordinary skill in the art that there are variety of 
implementations for both the traffic modem and the control link modem that will be 
referred to collectively as modem units. In one embodiment of the invention, the modem 
units may comprise a handset that is connected to the control unit using a special serial 
cable. In an alternative embodiment of the invention, the modem units may comprise a 
modem module that is connected to the control unit using a special serial cable. In another 
embodiment of the invention, the modem units may comprise a PCMCIA card that is 
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connected to the control unit using a PCMCIA socket. In a further embodiment of the 
invention, the modem units may comprise a custom modem that is implemented on either 
a separate printed circuit board or on the same printed circuit board as the control unit. In 
another embodiment of the invention, the modem units may comprise a software-defined 
radio (SDR) in which most of the radio functionality is implemented in software. The 
software can be running either on a separate printed circuit board or on the same printed 
circuit board as the control unit. In an alternative embodiment of the invention, the control 
link modem may comprise a 2-way data device, such as the RIM Blackberry or Motorola 
CreataLink, which interfaces to the control unit via a serial connection. 

119. The traffic modem 310 is selected so that it can work over a wireless network 
using a particular wireless standard. For example, the wireless network can be AMPS, 
iDEN, CDMA, TDMA, GSM, ARDIS, MOBITEX, or CDPD. It should be noted that 
these standards are listed as examples and are not meant to limit the scope of the 
invention. It is well known to those of ordinary skill in the art that other wireless network 
standards such as W-CDMA, PHS, i-Burst, NAMPS, ETACS, WLL, UMTS, TETRA, and 
NMT may also be supported just to name a few more examples. 

120. The traffic modem 310 may implement more than one wireless standard. For 
example, QUALCOMM manufactures dual mode phones that support both CDMA and 
AMPS operation. In addition, if the traffic modem 310 is implemented using a software- 
defined radio then it is possible to implement all of the above-mentioned standards using a 
single hardware platform. 

121 . The control link modem 308 is also selected so that it can work over a wireless 
network using a particular wireless standard. For example, the wireless network can also 
be AMPS, iDEN, CDMA, TDMA, GSM, ARDIS, MOBITEX, or CDPD. A primary 
factor in selecting a wireless standard for the control link modem is the pricing policy for 
transmitting control link information. 

122. FIG. 3c shows another architecture for the remote unit 300 with a control link 
modem and multiple traffic modems 310-1 - 310-N in accordance with a further 
embodiment of the invention. FIG. 3c differs from FIG. 3b because it includes multiple 
traffic modems rather than a single traffic modem. The remote unit 300 architecture of 
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FIG. 3c includes a control unit 302 that is connected to a location unit 304, control link 
modem 308, and traffic modems 1 (310-1) through N (31 0-N). 

123. FIG. 3d illustrates a remote unit according to one embodiment of the present 
invention that includes multiple peripherals. The remote unit 300 architecture of FIG. 3d 
includes a control unit 302 that is connected to a location unit 304, a control link modem 
308, traffic modems 1 (310-1) through N (310-N), battery backup 312, external storage 
314, a wireless LAN device 316, and an RF scanner 318. The location unit 304, control 
link modem 308, and traffic modems 1 (310-1) through N (310-N) are implemented in the 
same manner as discussed above with reference to FIG. 3c. 

124. The battery backup 312, shown in FIG. 3d, provides power to the remote unit 300 
when the main power is not available. If the remote unit 300 is mounted in a vehicle, the 
battery backup 312 is used when the vehicle ignition is turned off in order to ensure that 
the remote unit 300 does not drain the vehicle battery while the vehicle is parked. If the 
remote unit 300 is mounted in a stationary location, the battery backup 312 may be used to 
provide power if the main power is cut off due to a power failure in the building. In 
accordance with one embodiment of the invention, the battery backup 312 includes a 
battery and a battery charger. The battery can be made from a variety of known 
rechargeable technologies such as sealed lead acid, NiCad, NiMH, and Lithium for 
example. 

125. The external storage 314 provides a temporary storage capability for data that is 
not immediately sent back to the back end processor 224. There are a variety of reasons 
for storing data in the external storage 314. For example, if layer 3 network data is 
collected for the wireless network it is possible to produce 1 Mbyte/hour/technology of 
data. It may be prohibitively expensive to send this much data back to the back end 
processor 224 via the control link modem 308. Accordingly, the data can be stored locally 
in the external storage 314 and be downloaded at a later time using an alternate path. 

126. As another example, the collected data may be queued for transmission when the 
vehicle ignition is turned off. It may be preferable not to transmit the stored data until the 
ignition is turned back on in order to prevent unnecessary draining of the battery backup 
mechanism 312. Accordingly, the data can be stored locally in the external storage 314 
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and queued for transmission in at a later time over the control link modem 308 when the 
vehicle ignition is turned on. 

127. It is well known to those of ordinary skill in the art that the external storage 314 
can be implemented in a variety of ways. For example, the external storage is 
implemented as a PCMCIA Flash card that plugs into a PCMCIA socket on the control 
unit. As another example, the external storage 314 can be a SANdisk that is connected to 
the control unit via a proprietary connector. Alternatively, the external storage 314 is 
implemented using a moving storage device such as a specialized hard drive, for example 
a PCMCIA hard drive module. However, in mobile environments it is preferable to 
implement the external storage with no moving parts in order to improve the reliability of 
the remote unit. 

128. The wireless LAN device 316 allows high-speed data transmission over short 
distances. In accordance with an embodiment of the invention, the wireless LAN device 
316 is implemented, for example, using Bluetooth technology. The wireless LAN device 
316 provides an alternative path for downloading data that is stored on the external storage 
314. For example, if the remote unit 300 is mounted in a taxi and layer 3 wireless network 
data is stored from an earlier collection operation, then the wireless LAN device 316 is 
free to communicate with a wireless LAN controller (not shown) located at the taxi 
dispatch center in order to transmit the data back to the back end processor 224. As an 
alternative example, the wireless LAN device 316 can be used to communicate with a 
local I/O device (not shown) that can be used in a delivery truck to allow communications 
between a central dispatch and the delivery truck operator. 

129. The RF scanner 318 allows increased functionality for the remote unit 300 by 
increasing the capabilities for performing RF optimization of the wireless network. The 
RF scanner 318 allows the collection of more RF data then is traditionally available 
through the traffic modems (310-1 - 310-N). For example, the RF scanner 318 has a 
much more flexible input bandwidth since it is not forced to listen to a single traffic 
channel on the wireless network. Additionally, if the RF scanner 318 is optimized for 
CDMA collection, it can collect a variety of valuable CDMA network parameters such as 
measuring Io in the channel, despreading the spreading codes, measuring Ec/Io, and 
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measuring chip delay. The RF scanner 318 can be implemented by using a commercial 
scanner or by developing a custom scanner, for example, using a software-defined radio. 

130. FIG. 4a shows a hardware implementation of the remote unit 400 using either a 
laptop or handheld unit 402 in accordance with one embodiment of the invention. The 
laptop or handheld unit 402 is connected to a GPS receiver 404, control link modem 408, 
and traffic modem 410. The laptop or handheld unit runs any of a variety of operating 
systems such as Windows 95/NT/CE, Linux, or Palm OS, for example. The peripheral 
devices 404, 408, 410 are connected to the laptop or handheld unit 402 via serial ports, 
PCMCIA ports, Ethernet, or USB as appropriate. The laptop or handheld unit 402 should 
have device drivers for all of the peripheral devices that are either built into the operating 
system or written in a higher-level language. Furthermore, the laptop or handheld unit 402 
runs a main program that allows extraction of the location information from the GPS 
receiver 404 and sends and receives communication over the control and traffic channels. 

131. FIG. 4b shows a hardware implementation of the remote units using a single board 
computer (SBC) in accordance with one embodiment of the invention. The single board 
computer can be purchased off-the-shelf from a variety of vendors such has SBS, ADS, or 
Datalogic for example. Alternatively, the single board computer can be custom designed 
for the specific remote unit application. FIG. 4b shows a typical architecture for the single 
board computer including a microprocessor 420 which is connected via an address and 
data bus to a boot ROM 424, Flash memory 426, DRAM/SRAM 428, a PCMCIA socket 
430, a UART 432, a USB interface 434, an Ethernet interface 436, a CAN interface 438, a 
wireless LAN device 440, and an optional A/D & D/A interface 442. The microprocessor 
420 may also have direct connections to a temperature sensor 444, display interface 446, 
and general-purpose I/O. Additionally, the single board computer may include power 
management circuitry 448 that is connected to switched power, power, and ground, and 
additionally connected to an optional backup battery 450. 

1 32. It is well known to those of ordinary skill in the art that the single board computer 
can be implemented using a variety of different technologies. For example, the 
microprocessor can be a StrongARM, ARM, Pentium, PowerPC, Motorola 68000, and the 
like. Furthermore, a variety of operating systems are available such as Windows CE, 
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Windows 95/98, Windows NT, Linux, Palm OS, VXWorks, OS-9, PSOS, and the like. 
The serial ports from the UART 432, or directly from the microprocessor 420, are used to 
interface to peripheral devices such has the traffic modem 410 or the GPS receiver 404 
and should have configurable bit rates, word size, start bits, stop bits, parity bit and the 
ability to operate at either TTL or RS-232 voltage levels. 

133. FIG. 4c shows the organization of a software-defined radio in accordance with an 
alternate embodiment of the invention. All of the elements of the software-defined radio 
460 can be combined in any combination depending on the requirements. The elements 
include an RF scanner 462, a control link modem 464, traffic modems 1 (466-1) through N 
(466-N), a location unit 468, and a wireless LAN device 470. The advantage of using a 
software-defined radio architecture is that it allows implementation of multiple standards 
simultaneously on a single hardware device. This can greatly reduce the cost of the remote 
unit. The underlying architectural concepts for the software-defined radio 460 are well 
known to those of ordinary skill in the art and are discussed in articles in numerous 
journals such as the IEEE Communications Magazine. 

134. FIG. 4d illustrates organization of the software in the remote unit in accordance 
with an embodiment of the invention. At the lowest level is the operating system 476 that 
provides basic functionality for the hardware platform. The remote unit can run a variety 
of operating systems such as Windows 95/NT/CE, Linux, Palm OS, VXWorks, QNX, or 
pSOS for example. Furthermore, depending on the requirements, it is possible to use no 
operating system and write platform-specific code to implement the lower level routines. 

135. At the next level, the remote unit software includes device drivers 478, utilities 
480, protocols, 482 and user interface modules 484. The device drivers 478 allow 
communication with the peripheral devices such as the GPS receiver 404 and the wireless 
modems, for example. The utilities 480 support lower-level functions such as encryption 
and compression, for example. The protocols 482 support any protocols that are needed in 
the remote unit such as a WAP browser, TCP/IP, X.25, and any proprietary packet 
protocols, for example. The user interface module 484 includes all of the functionality 
required for local control of the remote unit such as a simple menuing system. It is well 
known to those of ordinary skill in the art that some or all of these modules may also be 
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built into the operating system. 

136. At the next level, the remote unit software optionally includes a variety of 
additional modules such as a pre-processing module 486, DB/Storage module 488, and a 
software-defined radio module 490. The pre-processing module 486 may be used to pre- 
process the collected data. This is particularly helpful in an operational scenario in which 
large quantities of data are collected and need to be reduced in order to conserve control 
link bandwidth. The DB/Storage module 488 may be used to store and organize the 
requested missions and/or the collected data. The software-defined radio module 490 is 
implemented as described above with reference to FIG. 4c. 

137. The main application 492 is at the next level and performs the higher-level 
routines. For example, the main application 492 is used to receive missions over the 
control link, execute the missions, and transmit the mission data over the control link. 

138. In the implementations described above, the control unit 302 is shown as being a 
general purpose computer in the form of a laptop or handheld unit 402. Although this has 
certain advantages in terms of flexibility of programming, the invention may also be 
implemented using special purpose computers in lieu of general purpose computers. 



139. FIG. 5a shows the architecture of the back end processor 500 in accordance with 
one embodiment of the invention. The back end processor 500 includes the following 
processing elements: fleet management 502, test traffic generator 504, post processor 506, 
user interface 508, portal 510, mapping 512, and billing and accounting 514. These 
processing elements are interconnected by a data network 516. It is well known to those 
of ordinary skill in the art that the data network 516 can be either a LAN, WAN, inter 
processing communications within a computer or network, or any combination of the 
above. 

140. FIG. 5b shows the architecture of the back end processor 500 in accordance with a 
further embodiment of the invention. The back end processor includes the following 
processing elements: fleet management 530, test traffic generator 532, post processor 534, 
user interface 536, and portal 538 including a mapping element 538a and a billing and 
accounting element 538b. In addition, the fleet management element 530 is connected to 
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a collected data database 540, mission database 542, and remote unit database 544; the 
post-processing element 534 is connected to a post-processed database 546 and the 
collected data database 540, and the portal 538 is connected to a mapping database 548 
and a billing and accounting database 550. 

141 . The fleet management element 530 is the main interface in the back end processor 
for communicating with the remote units. The fleet management element keeps track of 
the remote units by accessing data in the remote unit database 544, performs mission 
planning and coordination based upon information provided from the user interface 536, 
sends and receives information to the test traffic generator 532 in order to generate 
terrestrial originated calls, and sends and receives commands and responses to the remote 
units via the control link. 

142. The fleet management element 530 receives mission requests from the user 
interface 536 and stores the information in the mission database 542. It then performs a 
scheduling function based on the requested missions stored in the mission database 542 as 
compared with the remote units available as determined by availability information stored 
in the remote unit database 544. The scheduled missions are stored in the mission 
database 542 as requested missions and are sent at the appropriate time to the remote units 
over the control link. The requested missions can be stored and sent as a batch of missions 
or can be sent as individual missions depending on the requirements. 

143. The information received by the fleet management element 530 is stored in the 
collected data database 540 and forwarded to the post processor element 534 that stores 
raw mission data and also performs post processing and stores the post processing results. 

144. The £ost processing involves processing of the received data for either RF/network 
parameters related to the wireless system or statistical information related to the wireless 
data access. 

145. The analysis of the RF/network parameters can be accomplished in a variety of 
ways such as those discussed in Provisional Patent Application No. 60/149,888 entitled 
"Wireless Telephone Network Optimization" that was filed on August 19, 1999, and 
which is incorporated by reference herein in its entirety for all purposes. This provisional 
disclosure provides a simulation environment to develop optimum coverage-related 
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parameters for sectors of a wireless network. This simulation environment allows a 
network engineer to vary parameters of a virtual model of the wireless network and 
observe how the changes affect coverage. The provisional disclosure further provides an 
optimization algorithm to optimize hand off timing parameters for sectors in a wireless 
network. The optimization algorithm analyzes measured data regarding network coverage 
and regional terrain to arrive at a report containing recommended values for window size 
parameters (code division systems) or time advance parameters (time division systems). 

146. The post processing for statistical analysis involves the wireless data access that is 
accomplished using the traffic modem in the remote unit. The statistical analysis allows 
the combination of various collected information in order to produce reports for specific 
customers. For example, the latency of WAP accesses to a specific URL is measured over 
several different wireless networks and displayed on a bar graph. Further examples of 
statistical analysis and report generation are discussed in the operation section with respect 
to FIGS. 8a-8f. 

147. The user interface element 536 is connected to the fleet management element 530 
in order to schedule missions based on requirements entered by the customers. 
Additionally, the user interface element 536 is connected to the post-processing element 
534 to allow users to generate special queries, access previously stored queries, or access 
reports that are generated from the post processed data. The user interface element 536 is 
also connected to the portal 538 to allow access for the customers 560 from a connected 
data network such as the Internet 562. 

148. The portal element 538 acts as an operating system providing a variety of low-level 
functions for multiple applications. The portal 538 includes a mapping element 538a and 
a billing and accounting element 538b. The portal 538 is connected to databases 548, 550 
for the mapping information and the billing accounting information. In addition, the portal 
538 is connected to the data network 562, such as the Internet, to allow customer entry 
into the system. The portal is also connected to the post processor 535 to allow access of 
the post-processed data for visualization with the mapping software, for example. 

149. FIG. 5c shows the architecture for the portal 570 in accordance with one 
embodiment of the invention. The portal 570 acts as an operating system providing 
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common low-level functions for a variety of applications and acting as an interface for 
customer access through the Internet. The portal 570 functions are organized into four 
major groups: databases 572, GUI controls 574, workgroup functions 576, and security 
578. The database 572 functions include terrain, morphology, buildings, and billing and 
accounting. The GUI controls 574 include mapping/GIS, charts, and virtual reality. The 
workgroup functions 576 include access controls and threaded dialogue. The security 
functions 578 include login, partitioning, and audit trails. The portal also includes an API 
580 that allows access to various applications. 

IV. Control Link Communication Protocol 

150. The control link allows communications between the multiple remote units and the 
back end processor. There are a variety of possible protocols for the control link. The 
communication protocol can be a standard protocol such as TCP/IP, WAP, or X.25, for 
example, or a proprietary protocol that is optimized for the required communications, or 
some combination of a standard and proprietary protocol. 

151. In accordance with one embodiment of the invention, a proprietary packet protocol 
is used. One issue regarding the packet protocol is the issue of acknowledgments for 
packets. 

1 52. Acknowledgments can be handled in a variety of ways. They can be sent as an 
individual packet for each substantive packet sent. This is the heartiest mechanism but it 
is bandwidth inefficient. Alternatively, acknowledgments can be sent as a field of a 
subsequent packet using a packet numbering scheme to indicate which previous packet is 
being acknowledged. This method requires more overhead at each end of the 
communication link in order to keep track of previously sent packets, but is more efficient 
in terms of bandwidth used. As another alternative, the acknowledgment system can be 
handled by the communication system itself so that the packet protocol does not have to 
address the issue. For example, many two-way data systems have a built-in 
acknowledgment system so that packet delivery is virtually guaranteed. In this case, it is 
not required to include acknowledgments in the packet protocol since they are handled at 
another level. 

153. There are two basic types of packets: signaling packets and data packets 
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154. The signaling packets are originated either at the remote unit or at the back end 
processor. Some examples of remote unit originated packets are ignition on, ignition off, 
and status update. The Ignition on packet indicates that the vehicle ignition has been 
turned on and the ignition off packet indicates that the vehicle ignition has been turned off. 
These packets are used by the back end processor in order to properly schedule data 
collection in a mobile remote unit. The status update packet indicates the current status of 
the remote unit. 

155. Some examples of back end originated packets are reset and status request. The 
reset packet is used to remotely reset the remote unit. The status request packet is used to 
remotely request status information for a remote unit. 

156. The data packets are also either originated at the remote unit or at the back end 
processor. The back end originated data packets generally consist of mission requests and 
the remote unit originated data packets generally consist of mission data. 

157. FIG. 6a shows examples of some of the fields in the remote unit originated packets 
(both data and signaling) 610 in accordance with one embodiment of the invention. Some 
examples of the packet fields include a packet type ID 610a, remote unit ID 610b, date 
and time 610c, message number 610d, mission ID number 610e, location information 
610f, payload information 610g, and checksum information 610h. The packet type ID 
field 610a indicates the type of packet so that the back end processor will know how to 
parse the packet for the proper fields. The remote unit ID field 610b is used to identify 
the remote unit sending the packet. The date and time field 610c indicates the date and 
time that the measurement is taken. The message number field 610d is used to keep track 
of the message for acknowledgment purposes. The mission ID number field 610e is used 
by data packets to indicate the corresponding back end mission that caused generation of 
the packet's payload information. The location information field 61 Of indicates the remote 
unit location at the time of data collection. The checksum information field 610h is used 
in order to ensure the integrity of the packet information. The term checksum is used 
generically to refer to any type of error correction and/or error detection method to ensure 
packet integrity. 

158. The remote unit originated data packet's payload information field 610g can take a 
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variety of forms. It may include call statistics such as connect time, call duration, whether 
the call failed to connect or was dropped, and the like. Additionally, it may include basic 
RF engineering measurements such as RSSI, BER, FER, SQE, and the like. Furthermore, 
the payload information may include Layer 3 information that discloses call routing data 
and information regarding the configuration of the wireless network. The Layer 3 
information may be collected in totality or filtered by pre-processing in the remote unit 
depending on the amount of information desired. In addition, the payload may include 
application information such as the access latency for a WAP page or the delay in receipt 
of an SMS message. 

159. FIG. 6b shows examples of some of the fields in the back end processor originated 
packets (both data and signaling) 620 in accordance with one embodiment of the 
invention. Some examples of the packet fields include a packet type ID 620a, remote unit 
ID 620b, date and time 620c, message number 620d, mission ID number 620e, payload 
information 620f, and checksum information 620g. The packet type ID field 620a 
indicates the type of packet so that the remote unit will know how to parse the packet for 
the proper fields. The remote unit ID field 620b is used to identify the remote unit 
receiving the packet. The date and time field 620c indicates the date and time that the 
packet is sent. The message number field 620d is used to keep track of the message for 
acknowledgment purposes. The mission ID number field 620e is used by data packets to 
indicate the back end mission that will cause generation of the packet's payload 
information. The checksum information field 620g is used in order to ensure the integrity 
of the packet information. The term checksum is used generically to refer to any type of 
error correction and/or error detection method to ensure packet integrity. 

160. The back end processor originated data packet's payload information field 620f can 
take a variety of forms. It may include mission info regarding the type of data to collect 
including the type of access (WAP, circuit switched data, etc), a trigger related to the time 
(or range of times) to make the test call, a trigger related to the location (or range of 
locations) to make the test call, a wireless system to test (if the remote unit supports 
multiple wireless traffic standards), a target phone number or URL, and whether the call is 
mobile or terrestrial originated. 
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161. It should be noted that the packet field types described above are for illustrative 
purposes and in no way limit the actual fields that may be used. 

162. The information in the packet can be sent as either ASCII or binary data. ASCII is 
useful since some two-way data systems are used for paging and will only pass ASCII text 
information. Binary storage is useful because it is more bandwidth efficient than ASCII. 
Furthermore, the packet information can be compressed by a variety of standard methods 
such as null compression, run-length compression, keyword encoding, adaptive Huffman 
coding, Lempel-Ziv coding, and the like. Additionally, the packet information can be 
encrypted by a variety of standard methods such as DES, triple DES, RSA, PGP, and the 
like. 

163. In accordance with one embodiment of the invention, the packets are combined in 
larger files for transmission over the control link. This is advantageous in an environment 
in which the control network charges a fixed charge per packet. Accordingly, larger files 
may be more cost effective. Furthermore, it may be advantageous to store the collected 
information at the remote unit for transmission at a later time. This can occur if Layer 3 
information is collected since the data may be collected faster than it can be sent over the 
control link. Additionally, the collected information may be stored at the remote unit if 
the vehicle ignition is turned off during a mission in a mobile environment. This occurs 
because the system tries to reduce transmissions when the ignition is off in order to extend 
battery life. 

V. Method For Measuring 

164. FIG. 7a shows a method for measuring data quality of service in a wireless 
network in accordance with one embodiment of the invention. The method includes the 
steps of sending command information 702, performing measurements 704, and receiving 
response information 706. 

165. For example, the step of sending command information 702 may include using a 
back end processor to send either data or signaling packets to the remote units of a 
measuring system such as the one described previously. Furthermore, the step of 
performing measurements 704 may include performing any of a variety of measurements 
such as latency of wireless Internet access, e-commerce transactions, wireless messaging, 
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or push technologies. The step of receiving response information 706 may include 
responses to status inquiries or data related to the measurements collected during the step 
of performing measurements 704. 

166. FIG. 7b shows a method for measuring data quality of service in a wireless 
network, including at least one step related to the wireless network infrastructure, in 
accordance with a further embodiment of the invention. The method includes the sending 
702, performing 704, and receiving 706 steps described with respect to FIG. 7a. 
Additionally, the method includes steps of monitoring a WAP Gateway 710 and 
Benchmarking at a WAP Gateway 712. 

167. The step of monitoring the WAP Gateway 710 may include monitoring traffic 
through the WAP Gateway and providing metrics such as throughput, latency and lost 
packet information. Furthermore, the monitoring step 710 may allow the collection of 
protocol information directly from the WAP Gateway that may not be available to the 
multiple remote units. The step of benchmarking at the WAP Gateway 712 may allow 
latency measurements without including the uncertainties of the latency through the 
Internet or data network itself. This allows the provision of data indicating a breakdown 
between the latency of the wireless network and the data network. 

168. It is important to note that in regard to steps 710 and 712 that the closeness to the 
WAP gateway is described from a logical, not a physical, standpoint. It will be 
appreciated by those of ordinary skill in the art that these process steps can be 
accomplished with well known techniques in which the monitoring or benchmarking 
element is located far away from the WAP gateway. Furthermore as previously discussed, 
the term WAP is being used generically to describe any type of wireless Internet protocol, 
including HDML, WAP competitors, and any future wireless Internet protocols that may 
be developed. 

169. FIG. 7c shows a method for measuring data quality of service in a wireless 
network, including at least one additional order independent step, in accordance with 
another embodiment of the invention. The method includes the sending 702, performing 
704, and receiving 706 steps described with respect to FIG. 7a. Additionally, the method 
includes steps of accessing from the Internet 720, scheduling missions 722, generating test 
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traffic 724, storing at a remote unit 726, pre-processing at a remote unit 728, post- 
processing at the back end 730, and organizing remote unit information 732. 

170. The step of accessing from the Internet 720 may include the ability to access the 
measuring system from the Internet through a portal to set up missions and retrieve reports 
generated from the post-processed data, for example. The step of scheduling missions 722 
may include establishing parameters related to the specific data to be collected by the 
system. For example, these parameters may include some of the following: type of access 
- WAP, SMS, Instant Messaging, Push data, and the like.; type of Device - WAP, PDA, 
Pager, wireless modem, and the like.; trigger - time of call, location of remote unit, or 
some combination; wireless system - Sprint, Nextel, AT&T, and the like.; call Info - 
Target phone#, URL, type of transaction, etc; and mobile or terrestrial originated call. The 
step of generating test traffic 724 may include generation of SMS messages or other data 
packets to be sent to the remote units, for example. 

171. The step of storing at the remote unit 726 may include the storing of missions and 
of collected data at the remote unit. The step of pre-processing at the remote unit 728 may 
include processing received data prior to storing the data or transmitting it to the back end 
processor. The step of post-processing at the back end 730 may involve processing of the 
received data for either RF/network parameters related to the wireless system or statistical 
information related to the wireless data access. The step of organizing remote unit 
information may include storage of remote unit identification information in a remote unit 
database, storage of collected data in a collected data database, or storage of post- 
processed data in a post-processed data database, for example. 

172. It should be noted that the flow arrows in FIGS. 7a-7c are shown merely for 
illustrative purposes and do not reflect a required order for the method steps. 

VI. Operational and Business Model 

173. The previous sections of this description have discussed a method and system for 
measuring data quality of service in a wireless network using multiple remote units and a 
back end processor. The method and system may also include an element that is located 
within the wireless network infrastructure, for example, at the WAP gateway to monitor 
the wireless data protocol and to perform benchmarking measurements. 
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174. In light of those previous sections, the following section discloses the operational 
and business model for the system in accordance with a further embodiment of the 
invention. 

175. Rather than selling measurement equipment as a final product, the system, as 
defined by the invention, preferably sells the collected data and statistics generated from 
the collected data as the final product. The trade name for this service is preferably 
"Bitwise." The data and statistics generated by the system do not need to be real-time, but 
as previously disclosed the system will support near real-time data if desired. Typically, 
the data will be collected and analyzed over a period of time such as a day, week, month, 
or even a year depending on the user's requirements. 

176. The types of data collected include latency, call statistics (such as call completion, 
call dropped, etc), BER/FER, and various wireless network parameters such as RSSI and 
Layer 3 information. For example, the latency time is a measure of the access time for a 
WML page from a WAP server or the time to complete a Web transaction. Furthermore, 
the system can divide the latency measurement into the wired network and wireless 
network contribution through the use of a component located at the WAP gateway. 

177. Furthermore, the remote units can be used to perform additional functions that 
have value in vertical markets. For example, if the remote units are fielded in a mobile 
environment in a fleet of vehicles, the remote units can provide automatic vehicle location 
(AVL) in addition to data quality of service measurements. Additionally, the position data 
from the mobile remote units could be processed to provide near real-time traffic 
information that could be disseminated, for example, over the Internet. 

1 78. There are a variety of possible pricing strategies for the data and statistics produced 
by the system. The user may be charged per minute of system use or per transaction. 
Alternatively, the user may be charged per city, per wireless carrier, and per month for the 
requisite data and statistics. Furthermore, the post-processing element produces aggregate 
industry-wide statistics, for example comparing different wireless carriers or content 
providers, which is preferably packaged and sold as a separate product. 

1 79. The customers for the system have a variety of common attributes. They are 
dot.com and e-commerce companies that are targeting wireless device users by porting 
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their content and commerce to wireless web sites. Furthermore, they generally have a 
need for timely dissemination of content and transactions and have a keen interest in a 
positive customer experience. 

180. The customers can be divided into a variety of different groups. They can be 
wireless operators who wish to measure the performance of their networks in order to 
increase traffic and optimize performance. Furthermore, the customers can be wireless 
portals and/or ISPs such as AOL, Yahoo, Alta Vista, MSN, Lycos, and Excite, just to 
name a few examples. Additionally, the customers can be content providers in a variety of 
fields such as the service arena providing financial, weather, or traffic content; the internet 
auction arena involving time-sensitive bidding information; the instant messaging arena 
such as the AOL Anytime, Anywhere program; and the push data technology arena in 
which information such as airline information and traffic updates are pushed to the mobile 
device. 

181. The reasons that customers would use the system, in accordance with an 
embodiment of the invention, are fairly straightforward. It allows the customer to see the 
wireless Internet transaction through the end user's eyes in terms of their experience when 
accessing content and conducting transactions from wireless devices. In addition, it allows 
the customers a method for evaluating and comparing the performance of the wireless 
networks that are delivering the content. Furthermore, it allows the wireless operators and 
the content providers solid data to pinpoint bottlenecks and performance problems in the 
network. Additionally, it provides information to alert staff to critical service failures so 
corrective action can be taken in a timely manner. 

182. There are a variety of potential measurements that can be taken. Each 
measurement is referred to as a mission. Some examples of missions include retrieval of a 
WML page, completion of an e-commerce transaction, receiving pushed data content, 
performing a secure transaction, and performing benchmarking of different parts of the 
network by using a component located at the WAP gateway. 

183. There are a variety of methods for inputting requested missions. If the customer 
wishes, they can discuss their requirements with the system operator and allow the system 
operator to enter the missions. Alternatively, a user interface in the back end processor 



-35- 



Atty. Dkt. No.: 250* 




allows the customers to enter their own missions over the Internet by entering through the 
portal. 

1 84. The parameters for a mission may include at least the following items: 

Type of access - WAP, SMS, Instant Messaging, Push data, and the like. 
Type of Device - WAP, PDA, Pager, wireless modem, and the like. 
Trigger — time of call, location of remote unit, or some combination 
Wireless System - Sprint, Nextel, AT&T, and the like. 
Call Info - Target phone#, URL, type of transaction, etc 
Mobile or Terr. Originated. 

185. The output of the system can be obtained in a variety of ways. Generally, 
customers can set up formatted reports that will be generated periodically with the 
requested data and statistical information. The reports are obtainable in a variety of ways 
such as viewed using a Web browser, sent as an attachment to e-mail, sent as a file using 
FTP or some other protocol, or sent via normal mail just to name a few examples. The 
reports can be arranged in a variety of formats depending on the customer requirements 
with examples provided in the following figures. 

1 86. FIG. 8a shows a bar graph output 810 of download times from different portals, in 
accordance with an embodiment of the invention. The y-axis of the bar graph relates to 
the average download time in seconds and the x-axis relates to the city in which the 
measurement was performed. The three bars represent measurements for Yahoo, AOL, 
and a portal index of measurements over all portals. The statistics shown are for all 
wireless carriers, with a measurement interval of 15 minutes between 6 AM and 12 PM, 
for the period from 03/01/00 to 03/07/00. 

187. FIG. 8b shows a bar graph output 820 of download times across different wireless 
networks, in accordance with an embodiment of the invention. The y-axis of the bar graph 
relates to the average download time in seconds and the x-axis relates to the city in which 
the measurement was performed. The three bars represent measurements for Nextel, 
Sprint PCS, and AT&T Wireless. The statistics shown are for access to Yahoo, with a 
measurement interval of 30 minutes between 6 AM and 9 PM, for the period from 
03/01/00 to 03/07/00. 
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188. FIG. 8c shows a bar graph output 830 of call completion percentage across 
different wireless networks, in accordance with an embodiment of the invention. The y- 
axis of the bar graph relates to the call completion percentage and the x-axis relates to the 
city in which the measurement was performed. The three bars represent measurements for 
Nextel, Sprint PCS, and AT&T Wireless. The statistics shown are for access to Yahoo, 
with a measurement interval of 30 minutes between 6 AM and 9 PM, for the period from 
03/01/00 to 03/07/00. 

189. FIG. 8d shows a trending graph output 840 of call completion percentage across 
different wireless networks, in accordance with an embodiment of the invention. The y- 
axis of the bar graph relates to the call completion percentage and the x-axis relates to the 
city in which the measurement was performed. The three bars represent measurements for 
Nextel, Sprint PCS, and AT&T Wireless. The statistics shown are for access to Yahoo, 
with a measurement interval of 1 5 minutes between 6 AM and 9 PM, for the period from 
03/01/00 to 03/07/00. 

190. FIG. 8e shows a bar graph output 850 of average download times with a 
breakdown of the network latency at the WAP gateway, in accordance with an 
embodiment of the invention. The y-axis of the bar graph relates to the average download 
time in seconds and the x-axis relates to the city in which the measurement was 
performed. The bars represent measurements for Nextel with statistics shown for access 
to Yahoo, with a measurement interval of 60 minutes between 12 PM and 12 PM, for the 
period from 03/01/00 to 03/07/00. 

191. FIG. 8f shows a pie chart 860 of error statistics for wireless access of Yahoo, in 
accordance with an embodiment of the invention. The sectors of the pie chart show DNS 
lookup failure, connection timeout, page timeout, content errors, and successful error-free 
connections. The statistics represent error statistics for all carriers with statistics shown 
for access to Yahoo, with a measurement interval of 60 minutes between 1 2 PM and 1 2 
PM, for the period from 03/01/00 to 03/07/00. 

VII. Exemplary Embodiment 

192. Referring to FIG. 9, a system according to an exemplary embodiment of the 
present invention has two major components: Remote units (a.k.a. PUPPIs) 910, 920 
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which perform measurements related to Internet content delivery over wireless networks, 
and a Back End 930 that controls the remote units 910, 920 and performs data collection 
and storage. 

193. The basic control of the PUPPI 910 consists of commands sent from the Back End 
930 to the PUPPI 910 and responses sent from the PUPPI 910 to the Back End 930. The 
commands are generally missions that direct the PUPPI 910 to collect data from a 
particular wireless content provider within a particular time period. The responses are 
generally the results of these collection missions. The PUPPI' s physical interface to the 
control link 950 is a modem 912 that allows communication over a communication link 
940, such as the PSTN, or over a data network, such as the Internet. The control link 950 
can be implemented in a wired configuration, as shown in FIG. 9, or in wireless 
configuration using a wireless modem. 

194. The PUPPI's physical device for performing wireless measurements generally is a 
standard handset 914 that is connected to the PUPPI control unit via a serial cable. 
However, any wireless device such as a wireless modem module, PDA, RIM device, 
pager, etc can be used depending on the wireless network to be tested. Additionally, the 
software module with the appropriate WDP will be selected based on the wireless network 
to be tested. 

195. Referring to FIG. 10, the remote units (PUPPIs) in the exemplary system include a 
control unit 916 for controlling the remote unit, a test traffic modem 914 for performing 
measurements over the wireless network, and a control link modem 912 for passing 
commands and responses between the remote unit 910 and the back end processor 930 
(refer to FIG. 9). 

196. The control unit 916 may be implemented as a PC, a laptop, a handheld computer, 
or an embedded computer, to name but a few examples. The test traffic modem 914 may 
be implemented as a standard handset or a modem module, either of which should include 
an external antenna. The control link modem 912 may be implemented as a standard 
POTS modem (using a dedicated phone line), a DSL modem, ISDN modem, or an 
equivalent system. 

197. The internal hardware interface for the PUPPI is embodied as an RS-232 serial 
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connection between the control unit 916 and the test traffic modem 914 (generally a 
handset). Alternatively, the connection can be implemented using a USB port, Firewire 
port,, PCMCIA, or any other appropriate interface for the test traffic modem. The internal 
hardware interface between the control unit 916 and the control link modem 912 will 
depend upon the control link modem selected. If a standard V.90 modem (56.6 kbit/s) is 
used, then it can be housed inside the control unit case and plugged in to the PCI system 
bus or connected via an Ethernet connection over a LAN. If a DSL modem (or other 
advanced data modem) is used, then it will be connected to the control unit with an 
appropriate interface. If a wireless link control modem 912 is used, it will communicate 
with the control unit 916 via an appropriate interface, such as a serial port. 

198. The PUPPIs in the exemplary system are stationary indoor units or mobile units, 
including an external wireless antenna, under remote control from the back end using a 
special scripting language. 

199. The PUPPI is designed to simulate a subscriber using a WAP enabled handset or 
any WDP-enabled wireless device. WAP handsets have mini-browsers loaded onto the 
handset to allow this functionality. Because of limitations on the ability to control and 
track data on the handset itself, the exemplary remote unit may move the web browsing 
functionality from the handset to the control unit, where full browser control and data 
tracking is possible. In this case, the handset will be used for a dial-up networking 
connection which will provide access to the wireless data network, and will allow packets 
to flow between the WAP browser on the control unit and the WAP gateway at the 
operator's switch via the handset. 

200. The PUPPI software includes three main processes, a test process, a control 
process, and a logging process. The test process is responsible for all aspects of 
measurement. The control process is responsible for all communications with the Back 
End system. The logging process is responsible for logging all events from each process 
and generating alarms. 

201 . Referring to FIG. 1 1 , processes are illustrated that each contain software modules 
that are responsible for specific tasks. 

202. The Main Control Module (MCM) 1104 is responsible for all management and 
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control of the PUPPI unit. Some of the functions that the MCM is responsible for are 
listed as follows: 

• Tasking Modules with Measurements 

• Handling Timing Issues 

• Starting and Stopping Measurements 

• Responding to Diagnostics Requests 

• Receiving Task Lists 

• Sending Collected Data 

203. The test link connection module (TLCM) 1108 manages the test link connection. 
The test link connection is used by the data modules to collect information from the 
wireless data network. The test link connection includes of a dial-up networking 
connection to support modules requiring wireless data, and a direct handset connection for 
modules requiring transport information. 

204. The GPS module (GPSM) 1112 can optionally be included to provide GPS 
information to the Main Control Module. For example, the time information provided by 
the GPS Module can be used by the MCM to provide very accurate time stamps for the 
collected data. Furthermore, in a mobile environment the location information from the 
GPS Module can be used to provide position information. The term GPS is being used 
generically to refer to any type of position location technology including a distributed GPS 
(e.g. SnapTracks) and Time Difference of Arrival or Time Angle of Arrival (e.g. 
TruePosition). These additional forms of location determination may include the addition 
of a location server to the system. 

205. The WAP/WML data module (WDM) 1116 is responsible for performing all WAP 
related tasks. Embedded within the module will be WAP browser capabilities. The WDM 
is responsible for handling all WAP gateway login requests and security key exchanges. 
As previously discussed, the exemplary embodiment can include a WDM to collect data 
on any WDP, depending on the network that is being tested. 

206. The transport data module (TDM) 1120 is responsible for collecting all transport 
related data such as signal strength, quality, etc. This module is designed to be transport 
specific, and is loaded based on the transport technology being used (i.e. CDMA, iDEN, 
TDMA, GSM, etc.) Because data is collected differently for each transport technology, 
the module may be run in parallel with other modules (e.g. iDEN) or may need to be run 
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serially while other modules are not collecting data (e.g. CDMA). 

207. The SMS module (SMSM) 1124 is responsible for collecting SMS information 
related to a specific wireless network. For example, the SMS message can be either 
transmitted or received by the module. The SMS module is able to track the difference 
between the time of SMS transmission and reception in order to determine the latency in 
the system. 

208. The PDA module (PDAM) 1128 is responsible for collecting information related to 
PDA access of data via a wireless network. The possible PDAs to be used can include, but 
are not limited to, Palm, Pocket PC, Handspring, RIM, etc. 

209. The Push Notification Module (PNM) 1132 is responsible for collecting 
information related to data that is pushed via a wireless network to the remote device. For 
example, the Phone.com gateway includes a utility for pushing data to the remote device 
using WAP. There are a variety of other ways in which data can be pushed to the remote 
device. 

210. The Passive Monitoring Module (PMM) 1136 will be responsible for collecting 
information related to passive monitoring of a wireless network. This differs from the 
latency measurement function because there is no need for the process to generate any 
information (i.e. it only needs to monitor and passively receive information). For 
example, the PMM listens to the control channel and collects Layer 3 information. 

211. The Wireless Web Data Module (WWDM) 1140 will be responsible for 
performing tasks related to the chosen wireless web standard. This module is similar to 
the WAP/WML module but is used in networks in which other wireless web protocols 
(such as HDML, i-MODE, etc.) are used rather than WML. These protocols are 
generically referred to as WDP (Wireless Data Protocol). 

212. The HTML Data Module (HTDM) 1144 is responsible for performing HTML 
tasks. This module is similar to the WAP/WML module but is used in networks in which 
HTML is used rather than WML. 

213. The E-Mail Data Module (EDM) 1148 is responsible for performing e-mail tasks. 
This includes the ability to both transmit and receive e-mails at the remote device over the 
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wireless network. 

214. The FTP Data Module (FDM) 1152 is responsible for performing FTP tasks that 
involve the transmission of files. Although this module is referred as FTP (based on the 
TCP/IP file transmission protocol) this module will be able to implement a variety of file 
transmission protocols including future protocols which may be developed to move files 
over wireless networks. 

215. The Packet Sniffing Module (PSM) 1156 is responsible for performing packet 
sniffing tasks. This includes the ability to decode and log low level packet information 
similar to the functionality on a LAN packet sniffer. 

216. The Multimedia Data Module (MMDM) 1160 is responsible for performing tasks 
related to the transmission or reception of various types of multimedia data. For example, 
the multimedia data could be music files such as MP3 compressed music or some form of 
streaming video using a variety of different compression standards. 

217. The Status Module (StatM) 1164 is responsible for providing status information 
related to the remote unit. This is accomplished in any of a variety of alternative ways. 
For example, the Status Module can be responsible for providing periodic "heartbeats" 
which are monitored by the Back End to ensure that the remote unit is still alive and well. 
These heartbeats may be embodied a simple message which just states the unit is alive, or 
they may be embodied as more sophisticated messages including status information such 
as the available memory, amount of memory used, current configuration, temperature, etc. 
As another alternative, the system may be embodied with the Back End polling the remote 
units and the Status Module responding to the requests. In a further alternative, the system 
may include both heartbeats and polled status responses. 

218. The optional control link connection module (CLCM) 1168 manages (if 
implemented) the control link connection. The control link connection is used by the 
PUPPI unit to send and receive messages from the back end software. This module is 
optional and may be left out in implementations that use a higher level protocol to 
maintain the link between the remote units and the back end. For example, if the remote 
units run a database with setup info and collected data, the back end can communicate 
with the remote units by simply accessing their individual databases using remote database 
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communications. 

219. Each data module logs collected information to a local database via the logging 
module (LM) 1172. This module handles data logging requests from each module. 

220. The alarm module (AM) 1176 allows the setting of alarm conditions and produce 
alarms if an alarm condition is reached. For example, if data is being stored at the remote 
unit, an alarm condition may be set if the on-board storage is more than 80% full in order 
to prevent a storage overflow from occurring. 

221 . Each software module has a defined method of communicating with the PUPPI 
Main Control Module (MCM) 1104. The MCM 1104 has the ability to send requests to 
each module and receive responses. MCM 1104 requests may include status checks, 
tasks, etc. Each module will communicate with the logging module (LM) 1172 to log 
results. 

222. The WAP Data Module (WDM) 1116 communicates with the WAP Gateway 
using UDP. The Control Link Module (CLM) 1168 communicates with the back end 
server using TCP/IP. 

223. The exemplary system has remote control capability. A remote access application 
(e.g., PC Anywhere or an equivalent thereof) is loaded onto each PUPPI unit to allow full 
remote access to the PUPPI unit. This software is configured to automatically execute and 
enter a host mode when the machine is started. While running, the application remains in 
host mode, waiting for connections from external machines. 

224. The exemplary system also has application protection capabilities. Each PUPPI 
unit may include a special hardware card that can be used to force a machine reboot if 
software problems are encountered. The Main Control Module (MCM) 1104 will be 
tasked with monitoring each process to verify that each is running properly. If any process 
does not respond to the MCM's request within a predefined period of time, the hardware 
card will automatically reboot the machine. 

225. For a stationary PUPPI in a controlled environment, an exemplary PUPPI control 
unit is advantageously implemented as a standard rack mounted PC. For a mobile PUPPI, 
there are a variety of possible embodiments depending on the operating environment. The 
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PUPPI hardware can include a separate enclosure for shielding the handset from the PC. 
The handset enclosure includes access for a serial cable for control purposes and a port for 
an external antenna. 

226. In the event that multiple technologies are required at a remote location, a variety 
of options are available to implement them. For example, a single PUPPI unit with 
multiple serial ports can be set up to implement multiple technologies. The only limit to 
this approach is the processing power and storage capacity of the PUPPI to support 
multiple technologies. Alternatively, each PUPPI can support a single technology and be 
connected via a LAN with the ability to communicate with the Back End. 

227. Referring to FIG. 12, for example, a router 1200 is used as the interface between 
an external communication line 1210 (such as a DSL or dialup line) and a LAN 1220 that 
is connected to the PUPPIs 1230. 

228. In FIG. 13, the basic architecture for the Back End according to the exemplary 
embodiment is illustrated. 

229. The Back End performs the following major functions: 

• Performing fleet management of the PUPPIs to include sending commands and 
receiving responses using the control link, and performing queuing of missions 
based on measurement scripts 

• Maintaining a database of PUPPI information 

• Maintaining a database of requested and scheduled collection missions 

• Maintaining a database of collected data 

• Providing a user interface for entering collection mission tasking and extracting 
collected data 

230. The user interface 1310 to the system is a simple interface that allows users to 
prepare test scripts over the Internet 1320 to collect data, and to extract the collected data. 
The other major component of the Back End provides Fleet Management and Data 
Management for the PUPPI fleet 1330, the scheduled missions 1340, and the collected 
data 1350. 

23 1 . The Back End is implemented using commercial-grade PCs and standard software 
and database tools. 

232. The back end software preferably includes a fleet manager application, a 
centralized database server, and a web server. The fleet manager software allows the 
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system operator to do the following: 

• Define measurement 

• Assign measurements to PUPPIs 

• Query PUPPIs for diagnostic information 

• Start and stop PUPPI measurements 

• Query PUPPIs for configuration information 

• Schedule delivery of measurements 

• Query PUPPIs for measurement results 

233. All data collected from the PUPPIs is stored on a centralized database server. The 
database contains detailed information about the measurements, assignments, 
configuration information, etc. The data to be collected by the system is entered through a 
scripting language. 

234. Referring to FIG. 14, two basic software modules included in the Back End are 
illustrated. The modules, the Queue Builder Module 1410 and the Scheduler Module 
1420, convert the mission requests from the script to an actual mission to be executed on 
the PUPPI. 

235. The Queue Builder Module 1410 takes the information from the script and 
converts it to a queue of data collection missions for the PUPPIs. The scheduler 1420 
takes the information in the queue and converts it to a list of tasks at regular intervals (e.g. 
daily) that are sent to the PUPPIs and then executed. The resulting data is extracted from 
the PUPPI database 1430 after it is collected. 

236. Referring to FIG. 1 5, hardware architecture for the Back End according to the 
exemplary embodiment is illustrated. The Back End hardware includes, at a minimum, a 
scalable configuration of commercial servers 1510, 1520, 1530 that support 24/7 
operations. By design, significantly less data flows between a WAP client and server than 
between an Internet client and server. Many of the tasks handled by an Internet client (e.g. 
DNS lookup request and response) have been moved from the client to the server (or 
gateway) under WAP. Additionally, WAP-based WML pages differ from Internet based 
HTML pages. WML pages introduce the concept of decks and cards. WML pages 
contain decks that may have one or many cards. Each card is similar to a single page or 
screen view. A deck usually contains a collection of cards. When a user requests a URL 
from a WAP device, many times a deck with several cards is downloaded to the browser. 
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Once the entire deck is downloaded, the user can move between screens without 
requesting that new content be downloaded from the server. 

237. The exemplary system is configured to collect information that is specific to WAP- 
based browsing. The following metrics can be collected by the exemplary system. Web 
download would involve simulating a user downloading a single web page. Listed below 
is an example of the type of information that is collectable. 

• GET Time & Date 

The time and date that the browser issued a GET command requesting a URL. 

• URL Address 

Address of the URL being retrieved. 

• Deck Text Size 

The size in bytes of the text portion of the deck and all associated cards. 

• Image Count 

A count of the number of images embedded in a deck. 

238. For each image, the following information may be collected: 

• Image Size 

The size in bytes of the image. 

• Image Time 

The time to download the image. 

• Image URL 

The URL of the image. 

• Total Deck Time 

The amount of time required to download the entire deck and associated 
images. 

• Total Deck Bytes 

The total number of bytes within the deck (text and images) 

• Result 

Whether the web download was successful or not. 

239. Web navigation measurements involve simulating a user navigating to a page other 
than the page defined by the main URL. For example, a customer may desire to know 
how long it takes to navigate to the financial news section on the Bloomberg site. 

240. All of the information listed in the Web Download section can be collected for 
each deck that was downloaded as part of the navigation task. Additionally, the 
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information listed below may also be collected pending a technical assessment by Invertix. 

• Total Cards 

The total number of cards (or screens) to reach final destination. 

• Total Decks 

The total number of decks that had to be downloaded to reach final destination. 

• Total Navigation Time 

The amount of time required to navigate to the final destination. 

• Total Navigation Bytes 

The total number of bytes downloaded to navigate to the final destination. 

• Result 

Whether the web navigation was successful or not. 

241 . Web transactions generally involve components of the Web Download and Web 
Navigation methods. Web transactions are defined as any action that requires the user to 
input information to obtain some result. Some examples would include inputting one's zip 
code to retrieve the weather, inputting a ticker symbol to retrieve a stock quote; or 
inputting one's billing information to purchase a book. Web transactions would collect all 
of the metrics included above for Web Download and Web Navigation. Additionally, the 
information listed below may also be collected. 

• Time for Response 

Time for the network to respond to a user's input. 

• Result 

Whether the user input was accepted / successful or not. 

242. A full web transaction may require that a user input information on multiple 
screens. Metrics for each user input and response would be collected. The success or 
failure of a transaction would be based on the data that is returned in response to the 
request. 

VIII. Data Mining Functionality 

243. The disclosure thus far has emphasized the collection and storage of the data. 
However, the issue of handling the data in a manner that adds value to the end customer is 
valuable and adds to the economic viability of the system. The collected data can be 
warehoused and mined to produce added value. 

244. Telecom service providers (wireless carriers, ISPs, CLECs, ILECs, Satellite, and 
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IXCs) can build wireless data portals and integrate their back office stove-pipe data 
systems into a single data warehouse platform. In addition, telecom operators may build 
and operate wireless portals to make billing and other customer care data available to 
subscribers through an interactive, customizable Web and/or wireless data interface. 

245. A data translation application is configured to collect data from various vendor- 
independent business areas (billing, customer care, marketing, network performance, etc.) 
and host it in a single data warehouse with specific vertical dimensional partitions. The 
data warehouse's data mode is configured to facilitate and speed up reporting. 

246. According to a preferred embodiment, data mining is implemented (for example, 
using MicroStrategy's Intelligent E-Business Platform) so as to allow end users to use a 
graphical front-end web-based interface to perform analytical online queries on the 
underlying data and create reports tailored to specific needs. Report details range from a 
high-level management report where users can drill down and across to atomic-level data. 

247. Tools enable advanced call center management applications to do the following: 

• Increase employee productivity and reduce response times through detailed 
analysis of call volumes and patterns, 

• Improve call center effectiveness by reporting on trouble ticket resolution, 

• Make information available to the marketing staff for the development of customer 
campaigns, and 

• Increase customer loyalty by keeping them informed through personalized 
messaging about network performance and problem resolution. 

248. Effective marketing is critical for retaining customers as well as for acquiring new 
ones. Ensuring that customers have the optimal plan for their usage habits helps to boost 
revenue and reduce churn by enabling managers to plan marketing strategy to create new 
product offerings, analyze pricing, and assess the profitability impact of new offerings. 

249. A portal provides subscribers with a single point of access to information for data, 
analysis and dissemination. As a personalized web-based gateway to information, it 
allows users to subscribe to key information, personalize it for their needs, and specify the 
desired frequency for its delivery, all through a single web-based interface. As one 
example, such functionality is powered by Micro Strategy InfoCenter. The portal is 
designed for large-scale deployments and includes an asynchronous update server, a high- 
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speed interface cache, and clustering to meet the needs of large-scale implementations. 
Adaptable to many user requirements, the Telco Portal can provide the Telco Operator 
with the ability for its internal community to: 

• analyze costs and revenues, 

• adapt pricing and promotions maintain quality of service, 

• improve sales and customer service, 

• optimize customer loyalty programs, and 

• reduce churn. 

250. A portal also provides network operations and performance personnel with a 
powerful reporting tool that maps counties and trunk traffic activities. Daily, weekly, and 
monthly reports are automatically generated and pushed to appropriate personnel. Users 
Ef can set rules for alerts and have messages sent to their mobile devices based on certain 

03 criteria triggers. Such functionality is advantageously powered by MicroStrategy 

, ri Broadcaster. 

m IX. Combination of Diverse Systems 

s 251. The system is described as a stand-alone system in the explication of the 

Cl embodiments above. However, in accordance with a further embodiment of the invention, 

5 the system is combined with one or more secondary data collection systems. 

H 252. One such secondary data collection system functions to collect some of the same 

iL-JL 

data as gathered by a system according to the exemplary embodiment, above. This 
secondary system collects that data and sends it to a system according to the exemplary 
embodiment for processing. 

253. Another such secondary data collection system functions to collect data that is 
different than the data collected by the exemplary system. The data from the secondary 
system and the exemplary system are be combined, either pre- or post-processing, in order 
to produce value-added reports for customers. 

254. According to an alternative embodiment, a system embodied according to the 
present invention collects additional data (beyond the standard data types discussed above) 
that is then exported for use by the secondary system, either pre- or post-processing. 

255. Additionally, it is noted that a back end installation according to the present 
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invention is not limited only to the control of remote measurement units. The back end 
portion of a system according to the present invention is useful for providing scheduling, 
control, and data gathering for a variety of other system (for example, data collecting 
sensors, telecommunications network operation centers for either wired or wireless 
systems, telecommunication QOS network operation centers, surveillance and security 
systems, automated adjustment of wireless network base station parameters, etc.). 

256. A third implementation paradigm is also appropriate in the case of networks that 
already have well established back end operations. As opposed to the stand-alone and 
master controller paradigms discussed above, a back end according to the present 
invention may be implemented as an added set of functionalities as a part of an already 
existing network back end installation. Any additional hardware needed to implement the 
functions of the present invention's back end are simply integrated into those of an 
existing system, with the existing system being re-programmed to provide services as 
described above. 

257. The present invention has been described in accordance with a number of preferred 
embodiments. However, it will be understood by those of ordinary skill in the art that 
various modifications and improvements may be made to the invention as described, 
without departing from the scope of the invention. The scope of the invention is limited 
only by the appended claims. 
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